The /investigate agent could not check out the failure commit. Its
`git checkout <sha>` failed with "not our ref", and it fell back to
analyzing the default-branch tip -- the persistent problem reported for
the workflow. Prior fixes (the checkout-sha helper, then a git wrapper
that retried via snapshot-fetch) assumed GitHub's promisor rejects
object-level fetches for commits off the default branch. That was a
misdiagnosis: those failures were all observed inside the agent step,
where the credentials were already broken.

The real cause is in the action that runs the agent: in agent mode it
calls configureGitAuth during prepare, which removes the auth header
actions/checkout installed for CODE_REPO and repoints origin at the
workflow repo using the default GITHUB_TOKEN. By the time the agent
runs, origin no longer points at CODE_REPO and the credential is gone,
so any fetch the agent attempts -- including the lazy blob fetch a
checkout triggers -- hits the wrong repository and fails.

Stop relying on the agent's git for this. Resolve and check out the
failure SHA in a dedicated workflow step that runs while the
actions/checkout credentials are still active, then pass the SHA to the
agent and tell it the tree is already checked out. The SHA is taken
from an explicit `/investigate <sha>` trigger, otherwise the most
recent failure linked in the issue. On any failure the worktree is left
at the default-branch tip and the agent emits the existing warning.

This lets the git wrapper be removed (snapshot-fetch and checkout-sha
remain, now used by the workflow step). It also keeps INVESTIGATE_PAT
away from the agent: configureGitAuth still strips it before the agent
runs, so the token is never exposed to it.

Epic: none
Release note: none